I hadn’t been merging upstream changes while implementing, so I’m in the middle of merging them now...

Some things have changed in the past day-ish, watch out for incompatibilities/redundant re-implementations of these:

• -name and -port params are already in place in master; -ip param is parsed but not acted upon. add the supplied server to the ui #435 adds the passed server in the launch args to the connect list
• Add servers.txt so players can add an arbitrary amount of servers to the "Join Game" list #478 adds a server txt that will add all of the present servers to the connect list
• The base client executable has its own dedicated server now when running with -server

So -server has been added, I see.
From a quick look at the issues, it seems there are still a few world-related bugs remaining.

servers.txt is a nice addition as well.
It’s more user-friendly than -target.

It was partially affected by #495, but I was able to merge it without any issues.

is it still only LAN multiplayer only? or can worlds be opened up to more people?

It can be accessed from anywhere if you have a suitable network that can be accessed from the global internet (a network line that can open the specified TCP port).

In short, it's a regular server app.

oh damn. so i could run this on a vps?

Yes, but since it still uses a lot of Windows API internally (to maintain compatibility), it requires a Windows system or a system that includes Windows API to run.

I would like to eventually release a Linux version and put it into Docker.

i mean, i've tried it on linux and it works fine. i could try and create a docker image if you'd like

I would like to eventually release a Linux version and put it into Docker.

You can run it fine on Linux without a GUI launcher via umu

i mean, i've tried it on linux and it works fine. i could try and create a docker image if you'd like

seriously!
That's nice.

wine also works really well. tried lutris and has similar results to umu

Which one has a smaller image size?
wine or umu

wine iirc

Currently there are two approaches: the separated version (this pull request) and the -server option version (merged yesterday) that starts the client directly as a server. Which one should be prioritized?

The separated version modifies the world-saving logic and changes the startup logic, so integrating it into the client side would be a bit tricky.

Alternatively, it would also be possible to keep both.

Realistically speaking a completely separate Server executable should be our preferred way for this to work. The -server command line option is moreso jank and this is far cleaner.

If we're planning to merge the separated server in the future, I was considering removing the -server option and the unnecessary client-side logic as well. Would it be okay to leave them as they are for now?

If we're planning to merge the separated server in the future, I was considering removing the -server option and the unnecessary client-side logic as well. Would it be okay to leave them as they are for now?

Yeah

seems to be a bug where i cannot change the game's difficulty and enable some settings (trust players, pvp etc)


doing this all on a vps too

Sorry, that’s not written in the description, but it’s still a dummy for now.
It’s only included in the default server.properties generation ahead of time (so it can be implemented later).

doing this all on a vps too

Would it be possible to send the Dockerfile and docker-compose.yml?

doing this all on a vps too

Would it be possible to send the Dockerfile and docker-compose.yml?

not using a docker image, which is surprising. i took your pr build and ran it on my vps. works REALLY well, minus the default server settings being awful (peaceful mode, no pvp etc)

@hw2007

If shutdown save timed out occurs, isn’t the data just before the server shutdown saved? In the current logic, several save operations are performed during exit.

I found the cause!
The stop command was implemented rather hastily, so it immediately called MinecraftServer::HaltServer();. As a result, the required shutdown processes never finished and it ended up waiting indefinitely.

log.txt
Here's the log showing the server hitting the wait thread loop, it doesn't show the cause sadly.

It looks like something interesting has started in a pull request on my fork.
they’re planning to integrate a plugin system using Lua and C# into this separated Dedicated Server.

sylvessa:feature/dedicated-server

log.txt Here's the log showing the server hitting the wait thread loop, it doesn't show the cause sadly.

Did this happen when there was a lot of log output?
@goshavindtburg

Got a new log, this time I got a proper log output.
log (1).txt
[2026-03-08 06:05:01.559][DEBUG][client] [app] Trying to write to network, but the socketPlayer is NULL

Got a new log, this time I got a proper log output. log (1).txt [2026-03-08 06:05:01.559][DEBUG][client] [app] Trying to write to network, but the socketPlayer is NULL

Did the server hang at the point where the last log was printed?

Also, please be careful since the IP address is visible in the logs.

Got a new log, this time I got a proper log output. log (1).txt [2026-03-08 06:05:01.559][DEBUG][client] [app] Trying to write to network, but the socketPlayer is NULL

Did the server hang at the point where the last log was printed?

Also, please be careful since the IP address is visible in the logs.

The server hangs on the client's end when the socketPlayer stuff gets spammed, but I was able to close the server down and get it to save, which most of the time I can't.

This packet null error has existed for a while and also occurred in multiplayer on the client.
It might be a good idea to fix these here as well.

Most of the features have been added.
I’ll add whitelist if I feel like it.

I’ll be on a business trip for work starting tomorrow, so my responses will likely be very slow for a while.

What's the current status of this PR? c:

What's the current status of this PR? c:

The basic functionality (what you would want from a multiplayer server) is now in place at a minimum level.
It might be a good idea to merge it once and see how it goes.

Most multiplayer issues that appear later will likely originate from the client implementation, so it might be better to handle those fixes separately from this pull request.
As for adding new features, I’d like to continue doing that within this pull request.

i'm a little confused, where do worlds get stored? the server seems to autosave but... not save anything?

nevermind, you have to create the Windows64/GameHDD directory manually.

i'm a little confused, where do worlds get stored? the server seems to autosave but... not save anything?

nevermind, you have to create the Windows64/GameHDD directory manually.

Changed it so that GameHDD is automatically created if it does not exist.

If this is functional even with a few caveats I think we'd be okay to merge it in. Would rather have this be something everyone can help you with easily on main than leave you dangling in this PR for longer than needed if that's something you'd prefer. Otherwise no rush, we can wait for you to be ready.

When running this under Docker, how do I invoke commands to the server such as ban-ip? or is that impossible

When running this under Docker, how do I invoke commands to the server such as ban-ip? or is that impossible

By default std in is disabled so you need to enable it.
After starting with options, you need to specify the service and attach it.

tty: true
stdin_open: true

We'll commit these as defaults later.

i got a question about the server console commands, you've created new commands and such but i can also see inside MinecraftServer.cpp alot of existing/old commands?, like time, these arent currently connected to the terminal?

i got a question about the server console commands, you've created new commands and such but i can also see inside MinecraftServer.cpp alot of existing/old commands?, like time, these arent currently connected to the terminal?

Even though the function is available, I cannot use it because I have not registered it.
More will be added in the future!

Is there any reason for CLI specific commands rather than a unified command implementation? Bukkit/Paper/JE uses the concept of a CommandSender which can be the console or a player, and iirc there’s some base code in the project that could be used to accomplish something like that. It’d be better for maintainability to only have one set of commands if we can help it

please add a server properties setting that parses the world width into here

param->xzSize = 5*64; is chunk width
hell scale should be 8 for these large worlds

this value only effects newly generated worlds
Current limit seems to be 5*64 chunks hardcoded inside ChunkSource.h

large worlds seem like mostly ocean past the 54 chunk mark, im thinking theres another setting somewhere

To share my findings with server World size,
To set the size of newly generated words we can define that inside the current ServerMain.cpp here:

NetworkGameInitData *param = new NetworkGameInitData();
if (config.hasSeed)
{
	param->seed = config.seed;
}

+> //Set World Size For new Worlds
+> param->xzSize = 5*64; //(5*64);
+> param->hellScale = HELL_LEVEL_SCALE_LARGE;

param->saveData = worldBootstrap.saveData;
param->settings = app.GetGameHostOption(eGameHostOption_All);
param->dedicatedNoLocalHostPlayer = true;

LogStartupStep("starting hosted network game thread");
g_NetworkManager.HostGame(0, true, false, (unsigned char)config.maxPlayers, 0);
g_NetworkManager.FakeLocalPlayerJoined();

We can also expand small worlds already generated by setting some app options, also inside ServerMain.cpp:

app.SetGameHostOption(eGameHostOption_DoMobLoot, serverProperties.doMobLoot ? 1 : 0);
app.SetGameHostOption(eGameHostOption_DoTileDrops, serverProperties.doTileDrops ? 1 : 0);
app.SetGameHostOption(eGameHostOption_NaturalRegeneration, serverProperties.naturalRegeneration ? 1 : 0);
app.SetGameHostOption(eGameHostOption_DoDaylightCycle, serverProperties.doDaylightCycle ? 1 : 0);


+> //Upgrade World Size
+> app.SetGameNewWorldSize(64*5, true);
+> app.SetGameNewHellScale(HELL_LEVEL_SCALE_LARGE);

StorageManager.SetSaveDisabled(serverProperties.disableSaving);
// Read world name and fixed save-id from server.properties
// Delegate load-vs-create decision to WorldManager

Currently worlds beyond 64*5 chunks wide cannot be created because of a hardcoded limit inside ChunkSource.h
i think if we just bump this #define LEVEL_MAX_WIDTH (5*64) //(6*54) we can increase the world size further
Edit: raising the LEVEL_MAX_WIDTH seems to be crashing the server upon launch,

we just need to tie these values into a Dedicated Server Config file now so that we can easily define world sizes